Quote from UnknownMaster21 :

OTC = Open Track Configuration

Right!

I've been working on some more tracks, making path files, checking the layouts (adjusting a bit sometimes), adding support into Airio 2.5.6. These new tracks are done now: A16, A24, F15 (F12 + way around the tree island), F24 (minioval). While doing this I've noticed a few troublesome things:

F24R: Why go all around the FE3 track when doing the mini-oval in the opposite direction? I've changed the layouts so that both (F24 and F24R) use FE2X (going to the left from the pits, shortest way to the minioval), indicating the direction to join the oval using some layout objects. B23(R) is done in this way too.

A16R: There's a flaw in the split/finish line placement. From race start to split 1 it is actually faster than from finish to split 1, which is wrong, because then server best lap would always be someone's 1st lap. It is probably needed to make sure that on all tracks cars first cross finish line, then go to split lines and then back to finish line. I'll go through the strange layouts (where start is actually outside the race path) and do some corrections, probably moving splits, even if that means finish is on an opposite side of track...

Quote from UnknownMaster21 :

But it is okay (and just a plan right? )

Right, just a plan. And what is OTC?

Yesterday's additions: K21, F21 (not in official pack, just as FE4, but without FE1 Cadet part and with mini-oval).

Airio 2.5.6 with much better custom track support is now almost ready to be released. As I was explaining earlier, for this support it is very important to make sure correct layout is loaded. Correct layout, as recognized by Airio (and later by an intermediate application, if one is ever created) has two qualities: 1) Appropriate name (e.g. AS1Y_A12, which makes A12R track), and 2) all splits (and restricted zones) at the expected predefined absolute locations.

Overall, it would mean Airio does not care if some objects are added or removed from the default LYTs, but split count must not change, splits must not be moved, and predefined restricted zones must not be (re)moved. The default splits and zones must be defined such as to make sure the right sections of an open site have to be always used, even if some/all barriers are removed. I hope this makes sense.

As I was mentioning earlier, I had to adjust a bit some of default LYTs to adhere to the requirements, like moving a split to some other side of an intersection, or adding one more split somewhere, or defining certain restricted zones. This has left me with the appended set of default supported LYTs, that will be recognized and accepted by Airio, forming new custom tracks.

If you have time, please take a look at the layouts, we still have time for updates. However, when Airio 2.5.6 with the LYTs is released, it would not be possible anymore to change freely splits/zones, because that would create incompatibilities. So please review the split/zone positions, because they are most important. Any comments/ideas etc. are most welcome.

Just imagine there are no objects except the splits/zones in a layout and see if there are alternative ways around the open track that could give someone an advantage. If so, we should update the LYT so that this is not possible - by moving a split, adding a split, or adding a restricted zone. I can then update Airio hard-coded values to recognize only the updated LYT as the correct one.

Here's the list of my comments to individual custom tracks that are supported now, where I did some changes:

• A21, A21R - The split was moved to make sure correct track section is used. But maybe it should be moved still further up (to the north)?
  
• A23, A23R - Added one more split line to this relatively long track, again marking a required track section.
  
• K32, K32R - Moved one split to another oval section.
  
• F25, F25R - Moved one split to the mini-oval (but maybe it should be on the farthest point there?) and added a restricted zone close to the tree island.
  
• F21, F21R - Renamed to F51 and F51R to stress the fact it is a rallycross track. (Hm, maybe the split should be actually moved, or better yet, one more added?)
  
• F52, F52R - Rallycross Alternate track, going the other way around the tree island, with a restricted zone on the inside.
  
• B23, B23R - Major changes here, basically a completely remade layout. It has restricted zones and barriers preventing cars going directly through grass, for 2 reasons: 1) Using grass always invalidates AIRW laps, it is never a proper way to race, and 2) going straight to the big jump may be fun, but then it is not a racing track, it is pure demolition track. If the original layout creators insist on having it open, without zones, then I propose to change this layout name to B24. Note that if you want, you can change anything in the layout, except splits (position, width) and restricted zones (position, diameter).
  

Finally, here's the list of tracks I'd like to support in the near future. To me, these seem to be usable, interesting and sufficiently different from the existing tracks:

• F21 - proposed new track instead of rallycross (F51 now), combination of F22 and F13
  
• F24
  
• K21
  
• A16 - ideally I'd love to call this track A14, so that there is A11-A14 and A21-A24
  
• A24
  

And here's the preliminary list of tracks I do not plan to support for various reasons (too jumpy, too similar to existing tracks, too complicated):

• B21, B22
  
• F12, F13, F14
  
• F22, F23
  
• K33
  
• A15
  
• A25, A26, A27, A28, A29
  

What I'm trying to achieve is to make reasonably sure that when Airio recognizes some open track + layout configuration as a custom track, it will indeed be that one specific custom track, the same one on all Airios. When you have standard AS1 track, the game itself makes sure it is everywhere the same track, using the same parts of the AS site. However, this is more complicated with custom tracks. But still e.g. A11 should be the same under all Airios. But because it uses a layout, that anyone can change, making sure it really is A11 requires sometimes layout adjustments and always layout checks.

True, the path files can to a large extent make sure the "official" custom track lap times are consistent and correct, that WRs stored on AIRW are indeed the correct times. But path files alone cannot make sure the loaded layout conforms to A11 (or whatever) specifications. And I do not think you'll be happy to join a server with A11 (as reported by Airio Servers page), finding out it is actually a different track. Also, I can imagine ways some people may inadvertently or on purpose change the path files, with possible dire results for AIRW data. And moving splits in layouts will always have highly negative results, because split times or WRs are very important for good times reporting.

I'm not sure how much those AIRW data for custom tracks will be used. But there seem to be quite a few people loving all kinds of stats. When I some time ago removed all custom car lap times, because an inconsistency was discovered, I received some really unhappy comments. With the layout checks I'm trying to avoid these possible future problems. I hope this explains why I'm going quite deep into layouts, moving splits a bit sometimes, adding restricted zones at other times, and then checking these major parts of layouts in Airio.

Thanks for all your responses! You're right, the route checkers really do not do the job I would need, and they may complicate matters a lot. I was testing them a bit too...

However, it is very important to ensure unchangeable split positions. Also, ideally the splits should be put on such places where they ensure correct track sections are used.

Going through the currently supported layouts, I discovered maybe 2 tracks where small changes were needed, like moving the split point to the minioval (F25), moving splits to a bit different spots (A31, I think), and creating a new (2nd) split (A33, if I am not mistaken).

I hope the layout creators can live with these changes. What I'm trying to do is to get maximum safety that all the lap times on custom tracks are correct and mostly "uncheatable" by updating layouts (and path files).

I have all these layout checks done now. The code requires specific, hard-coded positions of split/finish lines and also of restricted zones, if they are justified. And they can be, I use restricted zone on F25 as additional safety measure.

Except for checklines and restricted zones the other objects can be freely added or removed, I believe this is the correct approach... Tomorrow, if time allows, I will upload here the updated layouts for your approval, comments, etc...

Again, thanks for the feedback. Airio 2.5.6 is almost complete now. When it is released, all current AIRW custom track lap times will be removed and only the ones coming from version 2.5.6 and newer will be accepted.

Hi and thanks for the layout updates!

I have created path files for two more tracks, F21 (rally long – I would rather call this track F51 to stress the fact it is a rallycross track) and F25 (classic). I believe the latest Airio updates are working well, the custom track support is doing what it is supposed to do.

However, there's a problem I was already hinting at earlier. The problem is how to make sure it is the official layout loaded and not some custom layout with the same name. Currently, only the layout name and number of splits in the layout are checked, then corresponding PTH file is loaded.

This is good enough for AIRW good laps and WRs, because path check is done. But there are layouts where people can cheat concerning their AIRW and server PBs. Such as making an F25 layout that allows you skip the mini oval or go through the faster side of that central tree island where FE2 and FE3 meet.

What I propose is to put route checkers, big enough so that people cannot miss them (if this is possible), into all such special places. I'm not sure how those checkers work, do they ensure that only proper laps are timed, and saved into stats and as AIRW PBs?

What I plan to do next is to check position of all splits and checkers of the loaded layout, which should make it very sure the proper layout is loaded. People still will be able to do changes to the layouts, like adding/removing some objects, but all splits and checkers will be guaranteed to stay at the original spot.

What do you think? Is this possible and meaningful?

Thanks for the report, notice taken, I hope to take a look at this problem today to have it corrected in Airio 2.5.6.

PS: Bug removed, display generally improved, it is ready for the upcoming version 2.5.6.

Last edited by EQ Worry, Thu, 7 Jul 2011 07:55.

Logging is always running, all events, infos, and errors are continuously stored into Aonio.log.txt file in Aonio folder.

Slightly updated Aonio version is now available using link in my signature. The most important thing is closer cooperation with Airio 2.5.5 and newer concerning recognizing custom tracks.

I was also trying to recreate that earlier mentioned bug with incorrect comparison data, but I failed. Does someone still experience problems with lap time/speed comparison?

Airio 2.5.5 FREE is released. I was not testing this compile as extensively, so if you find any bugs, please post the problems here. Also Airio 2.5.5 FULL/PROS was updated to solve some serious problems with custom tracks and layout tracks, all license owners should receive an e-mail notification.

Being in Italy on holidays now I do not have much time to explain, but generally speaking, you can change any item from CFG or SRV file (not TCD) using a !cfg command. So, to temporarily change pit windows, you can type something like !cfg PitWindows=... The change will be applied and you can later revert to standard server config using e.g. !rld.

Hi, it seems the admins purposefully specified 42.10, 42.00 and 41.90 as good lap times, hard-coded values. In such case the given values are always used as they are, regardless of WR. Airio allows to specify good lap times as percentages over WR (default) or specific target values (used in this case).

I see, yes, that is exactly the kind of troubles I would expect. The open tracks / custom layouts are very new, just as limiting available car types. While I checked the basic functionality, in real application various conditions raise that reveal holes that need to be covered. Any chance you could send me the log parts around those two events (unlimited joining, and no cars available)? That could help me a lot. I also had a report of normal layouts not being saved into Airio stats, so that's another matter I need to look at.

Voting for open tracks is something I plan to look into when I'm reasonably sure all the other code for custom tracks handling works OK, so I guess for now voting could do strange things.

But the safety rating not working on open/custom tracks is much more serious problem, I'll try to take a look at it today and see where the bug was introduced. Does it give an error or the test is simply passed for everyone?

Hmmm, good point, I guess only option 1) can be used in the FREE version...

Two options:

1) Set EnableStats=4 in the CFG file, then !rld.

2) Make yourself Limad5=d_cury, also in CFG, then !rld and reconnect.

After that all stats manipulation commands should work.

Yes, the libraries can be slightly different, and there is still more updated and tuned library in version 2.5.5 (only FULL and PROS released now).

The first one provided was just a quick patch. I included an improved library in Airio numbered 2.5.4, and I added all new LFS features into the library for Airio 2.5.5.

Overall, if you have Airio 2.5.4 and lower and everything works, there's no need to update the Aegio library. On the other hand with Airio 2.5.5 you should always use the provided latest library files.

Quote from cargame.nl :

It would really help if there was a midrace joining block, based on a predefined safety rate limitation.

Hmm, I have a feeling something like this can already be done, but I may be mistaken. Also the joining checks and various combinations make the whole matter real messy, but I'll try to take a look at this today, unless I'm flooded with Airio 2.5.5. bug reports.

Quote from cargame.nl :

Is it possible to take ProhibitedCars into consideration as well? ... So I reintroduced the old Airio Prohibited error, which, is a bit annoying for most.

I see. Is there a known error in the prohibited cars check, or do you simply use that word to describe the fact that people are unexpectedly specced for prohibited cars? I would think including prohibited cars in the !mycars check will not be too complicated. However, if the cars are also disabled for individual people or everyone, they need to be somehow restored later...

Great, thanks again! There's & GEN Open Racing server where I'm testing all these new layout things. Latest Airio and latest LYTs are now installed, so you may come and check. You're Limad4 so you may change anything (track, layout, cars), that is if you know the right commands, Boothy.

Great, thanks! Now I'll just quickly make sure the updated layouts are still recognized as custom tracks and then I'll release Airio 2.5.5 with the layouts included for easier testing. All FULL/PROS owners should receive a mail from me tonight, in 1 or 2 hours.

PS: I see A11, A12 and A13 are not included in the layout set.

SWELL!

PS: If you have time, please add F25 in the update, thx!

Well, where there is a new panel, there are some new config options, like position of the panel or behavior. In case the CFG file is not updated (file comparison is the best way to update), Aonio uses some hard-coded defaults. They are usually equal to the config specified in the default CFG file.

F25 is certainly an interesting track, I'd say it is the next one I want to convert to PTH and half-official support. It has two new spots, which is good for racing, but bad for PTH creation.

Another thing is reliability of the whole new code in Airio. While I was testing a lot, only real usage will uncover the remaining holes, and I'm sure there are some, situations I did not expect. I do not think it is a good idea to use very new code for a league race.

So, as I see it, there's just one way to go: Release Airio PROS 2.5.5 with initial custom tracks support. As any bugs are discovered, I may be able to correct them and at the same time work on F25 support. his all can then be either small 2.5.5 update or 2.5.6.

Well, yes. Just one thing I noticed during experiments: Split packets are rare but possible, merged (joined) packets quite very common. But even the simple code in one of my previous posts works OK. I believe Victor is right that creating new byte arrays constantly is not optimal performance-wise, but on the other hand it is simple and Airio never uses more than 1-3% of CPU power for normal processing, so... Uhm...

I'd like to release Airio PROS 2.5.5 tonight with initial support of some of the layouts available in this thread that have PTH files as well. Most things should work, but not all (most notably voting for layout tracks). Also the layout check is not yet perfect.

My question is: Can I include the supported layouts directly in Airio distribution (with appropriate info), or would you people working on the layouts prefer just a link to this thread? If they can be distributed, the layouts will have simple names such as A23.lyt or K32R.lyt for much easier loading.